Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add/move tests for Vc generics #8843

Merged
merged 1 commit into from
Jul 29, 2024
Merged

Add/move tests for Vc generics #8843

merged 1 commit into from
Jul 29, 2024

Conversation

bgw
Copy link
Member

@bgw bgw commented Jul 25, 2024

Description

  • Move the tests out of all_in_one so that we can see exactly which parts are failing more easily.
  • Add a few more tests. The newly added test_read_ref_round_trip fails (and is ignored), indicating a bug in the generics implementation!!! This is fixed in Fix ReadRef<T>::cell when T != T::Read::Repr #8845.

Why does test_read_ref_round_trip fail?

The theory is that Vcs are supposed to be stored as <<T as VcValueType>::Read as VcRead<T>>::Repr. However, it looks like due to an oversight, ReadRef::cell is trying to store the value as T.

Why add these tests at all?

The plan (as of yesterday) is to remove support for generics, but I'd feel more confident if I can fix the casting issues in my local Vc PRs before I do that.

These tests should help me understand what's happening and debug things.

Testing Instructions

cargo nextest r -p turbo-tasks -p turbo-tasks-memory

Copy link

vercel bot commented Jul 25, 2024

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name Status Preview Comments Updated (UTC)
examples-nonmonorepo ✅ Ready (Inspect) Visit Preview 💬 Add feedback Jul 29, 2024 5:56pm
rust-docs ✅ Ready (Inspect) Visit Preview 💬 Add feedback Jul 29, 2024 5:56pm
8 Skipped Deployments
Name Status Preview Comments Updated (UTC)
examples-basic-web ⬜️ Ignored (Inspect) Visit Preview Jul 29, 2024 5:56pm
examples-designsystem-docs ⬜️ Ignored (Inspect) Visit Preview Jul 29, 2024 5:56pm
examples-gatsby-web ⬜️ Ignored (Inspect) Visit Preview Jul 29, 2024 5:56pm
examples-kitchensink-blog ⬜️ Ignored (Inspect) Visit Preview Jul 29, 2024 5:56pm
examples-native-web ⬜️ Ignored (Inspect) Visit Preview Jul 29, 2024 5:56pm
examples-svelte-web ⬜️ Ignored (Inspect) Visit Preview Jul 29, 2024 5:56pm
examples-tailwind-web ⬜️ Ignored (Inspect) Visit Preview Jul 29, 2024 5:56pm
examples-vite-web ⬜️ Ignored (Inspect) Visit Preview Jul 29, 2024 5:56pm

Copy link
Member Author

bgw commented Jul 25, 2024

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @bgw and the rest of your teammates on Graphite Graphite

Copy link
Contributor

github-actions bot commented Jul 25, 2024

🟢 Turbopack Benchmark CI successful 🟢

Thanks

Copy link
Contributor

✅ This change can build next-swc

Copy link
Contributor

github-actions bot commented Jul 25, 2024

⚠️ CI failed ⚠️

The following steps have failed in CI:

  • Turbopack Rust tests (mac/win, non-blocking)

See workflow summary for details

@bgw bgw marked this pull request as ready for review July 25, 2024 21:38
@bgw bgw requested a review from a team as a code owner July 25, 2024 21:38
@bgw bgw requested review from arlyon and wbinnssmith July 25, 2024 21:38
@bgw bgw changed the title Add and move tests for Vc generics Add and more tests for Vc generics Jul 25, 2024
@bgw bgw changed the title Add and more tests for Vc generics Add/move tests for Vc generics Jul 25, 2024
Comment on lines +148 to +157
// Test that we can convert a `Vc` to a `ReadRef`, and then back to a `Vc`.
#[tokio::test]
#[ignore = "TODO: This panics! There's a casting bug in the generics implementation."]
async fn test_read_ref_round_trip() {
run(&REGISTRATION, async move {
let c: Vc<Option<Vc<u8>>> = Vc::cell(Some(Vc::cell(1)));
let _ = ReadRef::cell(c.await.unwrap()).await.unwrap();
})
.await
}
Copy link
Member Author

@bgw bgw Jul 25, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This panics due to a bug in the current generics implementation. Fixed in #8845

Copy link
Contributor

@arlyon arlyon left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The plan (as of yesterday) is to remove support for generics, but I'd feel more confident if I can fix the casting issues in my local Vc PRs before I do that.

Mind elaborating a little about removing generics?

Any other reviewers feel free to approve I just want to leave this open so I can close the loop and come back to it.

Copy link
Member Author

bgw commented Jul 26, 2024

Mind elaborating a little about removing generics?

Vc has very limited support for generic collections, such as Vc<Vec<Vc<T>>>: #5738

We discussed this during office hours, and decided that:

  1. The hack that generics use is not generalizable to all generics.
  2. Generics require a lot of support code with unsafe transmutes and rely on a lot of details about memory layout. It's very hard to get this right (and as I'm discovering, there are bugs!). Some level of this is needed anyways for transparent types, but generics make this even worse.
  3. There's not a lot of uses of these generics, though there might be more if there was more awareness of this feature.
  4. Switching things from Vc to ResolvedVc is going to add more complexity to the generics code.
  5. Transparent value types provide 90% of the benefits of generics.

So the agreement in the room between @sokra, @ForsakenHarmony, @wbinnssmith, and myself was that it's just not worth it, and we should remove it.

Copy link
Member Author

bgw commented Jul 29, 2024

Merge activity

  • Jul 29, 4:41 PM EDT: @bgw merged this pull request with Graphite.

@bgw bgw deleted the bgw/vc-generics-tests branch July 29, 2024 20:41
bgw added a commit that referenced this pull request Jul 29, 2024
## Description

Fixes the test case introduced in #8843.

The theory is that Vcs are supposed to be stored as `<<T as
VcValueType>::Read as VcRead<T>>::Repr`. However, it looks like due to
an oversight, `ReadRef::cell` is trying to store the value as `T`.

This introduces a way to perform 

## Testing Instructions

```
cargo nextest r -p turbo-tasks -p turbo-tasks-memory
```
ForsakenHarmony pushed a commit to vercel/next.js that referenced this pull request Jul 30, 2024
## Description

- Move the tests out of `all_in_one` so that we can see exactly which
parts are failing more easily.
- Add a few more tests. **The newly added `test_read_ref_round_trip`
fails** (and is ignored), indicating a bug in the generics
implementation!!! This is fixed in #8845.

## Why does `test_read_ref_round_trip` fail?

The theory is that Vcs are supposed to be stored as `<<T as
VcValueType>::Read as VcRead<T>>::Repr`. However, it looks like due to
an oversight, `ReadRef::cell` is trying to store the value as `T`.

## Why add these tests at all?

The plan (as of yesterday) is to remove support for generics, but I'd
feel more confident if I can fix the casting issues in my local Vc PRs
before I do that.

These tests should help me understand what's happening and debug things.

## Testing Instructions

```
cargo nextest r -p turbo-tasks -p turbo-tasks-memory
```
ForsakenHarmony pushed a commit to vercel/next.js that referenced this pull request Aug 1, 2024
## Description

- Move the tests out of `all_in_one` so that we can see exactly which
parts are failing more easily.
- Add a few more tests. **The newly added `test_read_ref_round_trip`
fails** (and is ignored), indicating a bug in the generics
implementation!!! This is fixed in #8845.

## Why does `test_read_ref_round_trip` fail?

The theory is that Vcs are supposed to be stored as `<<T as
VcValueType>::Read as VcRead<T>>::Repr`. However, it looks like due to
an oversight, `ReadRef::cell` is trying to store the value as `T`.

## Why add these tests at all?

The plan (as of yesterday) is to remove support for generics, but I'd
feel more confident if I can fix the casting issues in my local Vc PRs
before I do that.

These tests should help me understand what's happening and debug things.

## Testing Instructions

```
cargo nextest r -p turbo-tasks -p turbo-tasks-memory
```
bgw added a commit to vercel/next.js that referenced this pull request Oct 7, 2024
…70815)

Removes the uses of generic vc collections in
`next-core/src/app_structure.rs` and it's callsites.

## Why?

Rather than extended support for `Vc` generics to `ResolvedVc`, I plan
to remove support for them entirely. That means fixing all the callsites
(there's not many).

Removing this is needed to get us to a point where 100% of structs can
be `ResolvedValue`, because structs using these fields cannot otherwise
be ported over to `ResolvedVc`.

## Okay, but Why?

Explained here:
vercel/turborepo#8843 (comment)

I expect removing support for this will decrease the overall size of the
codebase, as the logic for supporting generics is rather complicated.
bgw added a commit to vercel/next.js that referenced this pull request Oct 7, 2024
…rics in non-test code (#70816)

After this change, `cargo check` on a branch that deletes vc generics
support compiles successfully.

## Why?

Rather than extended support for `Vc` generics to `ResolvedVc`, I plan
to remove support for them entirely. That means fixing all the callsites
(there's not many).

Removing this is needed to get us to a point where 100% of structs can
be `ResolvedValue`, because structs using these fields cannot otherwise
be ported over to `ResolvedVc`.

## Okay, but Why?

Explained here:
vercel/turborepo#8843 (comment)

I expect removing support for this will decrease the overall size of the
codebase, as the logic for supporting generics is rather complicated.
bgw added a commit to vercel/next.js that referenced this pull request Oct 8, 2024
The previous PRs in this stack remove the only uses/callsites. This
removes support for vc generics!

There's still a small bit of support left in the form of
`VcValueType::Repr`, but that touches more things, so that'll be a
follow-up PR.

## Why?

Rather than extended support for `Vc` generics to `ResolvedVc`, I plan
to remove support for them entirely. That means fixing all the callsites
(there's not many).

Removing this is needed to get us to a point where 100% of structs can
be `ResolvedValue`, because structs using these fields cannot otherwise
be ported over to `ResolvedVc`.

## Okay, but Why?

Explained here:
vercel/turborepo#8843 (comment)

I expect removing support for this will decrease the overall size of the
codebase, as the logic for supporting generics is rather complicated.
kdy1 pushed a commit to vercel/next.js that referenced this pull request Oct 10, 2024
…70815)

Removes the uses of generic vc collections in
`next-core/src/app_structure.rs` and it's callsites.

## Why?

Rather than extended support for `Vc` generics to `ResolvedVc`, I plan
to remove support for them entirely. That means fixing all the callsites
(there's not many).

Removing this is needed to get us to a point where 100% of structs can
be `ResolvedValue`, because structs using these fields cannot otherwise
be ported over to `ResolvedVc`.

## Okay, but Why?

Explained here:
vercel/turborepo#8843 (comment)

I expect removing support for this will decrease the overall size of the
codebase, as the logic for supporting generics is rather complicated.
kdy1 pushed a commit to vercel/next.js that referenced this pull request Oct 10, 2024
…rics in non-test code (#70816)

After this change, `cargo check` on a branch that deletes vc generics
support compiles successfully.

## Why?

Rather than extended support for `Vc` generics to `ResolvedVc`, I plan
to remove support for them entirely. That means fixing all the callsites
(there's not many).

Removing this is needed to get us to a point where 100% of structs can
be `ResolvedValue`, because structs using these fields cannot otherwise
be ported over to `ResolvedVc`.

## Okay, but Why?

Explained here:
vercel/turborepo#8843 (comment)

I expect removing support for this will decrease the overall size of the
codebase, as the logic for supporting generics is rather complicated.
kdy1 pushed a commit to vercel/next.js that referenced this pull request Oct 10, 2024
The previous PRs in this stack remove the only uses/callsites. This
removes support for vc generics!

There's still a small bit of support left in the form of
`VcValueType::Repr`, but that touches more things, so that'll be a
follow-up PR.

## Why?

Rather than extended support for `Vc` generics to `ResolvedVc`, I plan
to remove support for them entirely. That means fixing all the callsites
(there's not many).

Removing this is needed to get us to a point where 100% of structs can
be `ResolvedValue`, because structs using these fields cannot otherwise
be ported over to `ResolvedVc`.

## Okay, but Why?

Explained here:
vercel/turborepo#8843 (comment)

I expect removing support for this will decrease the overall size of the
codebase, as the logic for supporting generics is rather complicated.
kdy1 pushed a commit to vercel/next.js that referenced this pull request Oct 10, 2024
…70815)

Removes the uses of generic vc collections in
`next-core/src/app_structure.rs` and it's callsites.

## Why?

Rather than extended support for `Vc` generics to `ResolvedVc`, I plan
to remove support for them entirely. That means fixing all the callsites
(there's not many).

Removing this is needed to get us to a point where 100% of structs can
be `ResolvedValue`, because structs using these fields cannot otherwise
be ported over to `ResolvedVc`.

## Okay, but Why?

Explained here:
vercel/turborepo#8843 (comment)

I expect removing support for this will decrease the overall size of the
codebase, as the logic for supporting generics is rather complicated.
kdy1 pushed a commit to vercel/next.js that referenced this pull request Oct 10, 2024
…rics in non-test code (#70816)

After this change, `cargo check` on a branch that deletes vc generics
support compiles successfully.

## Why?

Rather than extended support for `Vc` generics to `ResolvedVc`, I plan
to remove support for them entirely. That means fixing all the callsites
(there's not many).

Removing this is needed to get us to a point where 100% of structs can
be `ResolvedValue`, because structs using these fields cannot otherwise
be ported over to `ResolvedVc`.

## Okay, but Why?

Explained here:
vercel/turborepo#8843 (comment)

I expect removing support for this will decrease the overall size of the
codebase, as the logic for supporting generics is rather complicated.
kdy1 pushed a commit to vercel/next.js that referenced this pull request Oct 10, 2024
The previous PRs in this stack remove the only uses/callsites. This
removes support for vc generics!

There's still a small bit of support left in the form of
`VcValueType::Repr`, but that touches more things, so that'll be a
follow-up PR.

## Why?

Rather than extended support for `Vc` generics to `ResolvedVc`, I plan
to remove support for them entirely. That means fixing all the callsites
(there's not many).

Removing this is needed to get us to a point where 100% of structs can
be `ResolvedValue`, because structs using these fields cannot otherwise
be ported over to `ResolvedVc`.

## Okay, but Why?

Explained here:
vercel/turborepo#8843 (comment)

I expect removing support for this will decrease the overall size of the
codebase, as the logic for supporting generics is rather complicated.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants